Conventionally, in cases where authentication is done by confirming only an identity of the user, or where providers of service, such as an online bank, already have means to confirm the user, there is a demand to improve the level of security of the protocol that authenticates the user by using a key pair. With regards to techniques for realizing user authentication with high level of security, many mutual authentication protocols that use certificates have been proposed. Such protocols include SSL (Secure Sockets Layer) client authentication protocol, IKE (Internet Key Exchange) mutual authentication protocol, and EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) protocol. As to these mutual authentication protocols, standards are established for using a key pair consisting of a public key and a secret key, and a digital certificate of the public key (public key certificate), and many kinds of products support these protocols. The public key certificate is usually issued by a certification authority (hereafter referred to as “CA”). The certificate includes data such as user's public key and identifier ID, and a digital signature generated using a secret key of the CA to the data.
When using such a mutual authentication protocol utilizing certificates, there is a problem in that the cost incurs for protecting the secret key of the CA and for processing the issuance of the certificates.
On the other hand, a protocol has been proposed which issues a certificate (self-signed certificate) using user's own key pair and authenticates the user using the self-signed certificate (refer to Non-patent literature 1). With the user authentication protocol using the self-signed certificate, it is possible to confirm the identity of the user by using user's key pair. In this case, since the CA is not used, there is an advantage that there is no need for the cost needed to protect the above-described secret key of the CA and to issue the certificates at the server side.
FIG. 1 shows a schematic view of a system for a user to be provided various services via the network. Connected to a network NW is a large number of user terminals 101, 102, . . . (hereafter, any one of which is referred to as a “user terminal 10”), a plurality of certification authorities 21, 22, . . . (hereafter, any one of which is referred to as a “certification authority 2”), and a plurality of service providers 31, 32, . . . (hereafter, any one of which is referred to as a “service provider 3”). Each of the service providers 31, 32, . . . includes respective user authentication apparatus 301, 302, . . . (hereafter, any one of which is referred to as a “user authentication apparatus 30”). However, as shown by the dashed line, a service provider 3 and a user authentication apparatus 30 may be provided independently. Each user terminal 10 can be provided desired services from any one of the service providers 3 via the network NW. There are various forms of service. For example, in cases where a user is to be provided a particular service, in many cases, user registration to the service provider that provides the service is required in advance, and the service provider provides the service only to those users registered oneself, non-free or free of charge. In such cases, the service provider needs to perform user authentication before providing a service in response to a service request from the user.
First, the user terminal 10 performs user registration to the user authentication apparatus 30 of the service provider 3 that provides the desired service. Then, the user terminal 10 accesses the user authentication apparatus 30 of the service provider at a point of time when it desires to be provided the service, the user authentication apparatus 30 performs user authentication, and the desired service is provided to the user if the authentication is successful. Each user can be provided one or more services at any time by registering oneself to one or more service providers 3. The user authentication apparatus 30 of each service provider authenticates a plurality of registered users in response to respective service requests to thereby provide the service.
Examples of a method for performing user authentication include a method that uses certificates issued by a CA, and a method that uses a self-signed certificate of the user terminal. In the former method that uses certificates issued by a CA, the user terminal requests the CA which the user authentication apparatus trusts to issue a public key certificate of the user that contains a signature calculated by using a CA secret key, and performs user authentication of the user terminal using the public key certificate of the user at the time of the service request. In this method, it is necessary for the CA to generate a certificate for each user and safely manage the CA secret key. Therefore, there is a problem in that the management cost of the CA increases.
Now, the latter authentication method that uses a self-signed certificate will be described below. FIG. 2 shows a flow of overall processing in a user authentication system using a conventional self-signed certificate. Shown here is processing between any one of the user terminals 10 in FIG. 1 and any one of the user authentication apparatus 30.
[Registration Phase]
(1) The user terminal 10 generates a key pair consisting of a public key PKU and a secret key SKU, for use with a desired service provider, generates a signature SIGU=SKU(PKU, INFU) corresponding to the public key PKU and information required for creating a certificate such as a user identifier IDU prepared in advance (user information INFU), using the secret key SKU, creates a self-signed certificate (hereafter referred to as a “terminal certificate”) CERTU={PKU, INFU, SIGU} containing the public key PKU, the user information INFU, and the signature SIGU (Step S11), and stores it in a storage device and transmits to the user authentication apparatus 30 of the above service provider, to thereby request the registration (Step S12). Here, SK (*) indicates a signature generated using a secret key SK for data “*”.
(2) The user authentication apparatus 30 verifies the user terminal certificate CERTU received from the user terminal 10 (Step S13), and if the verification is successful, associates the user information INFU contained in the terminal certificate or the user information INFU separately notified by the user, and the user terminal certificate CERTU or the terminal public key PKU contained in it, to thereby store them into the user information storage device (registration of user information) (Step S14).
In cases where the user uses a plurality of service providers, such registration is performed for each service provider that the user uses. Since the key pair and/or the user identifier IDU are newly generated for each service provider, the user retains a plurality of different terminal certificates (self-signed certificates) corresponding to each service provider.
[Utilization Phase]
(1) In response to a service request from the user terminal (Step S15), the user authentication apparatus 30 transmits a certificate request and a random number R to the user terminal 10 (Step S16).
(2) From the plurality of stored terminal certificates, the user terminal 10 lets the user select a terminal certificate corresponding to the service provider that the user desires to use. Then, the user terminal 10 makes a signature on data containing the random number R using the terminal secret key SKU corresponding to the terminal public key PKU contained in the selected terminal certificate (Step S17), and the signature SIGRU and the terminal certificate CERTU are transmitted to the user authentication apparatus 30 (Step S18).
(3) The user authentication apparatus 30 verifies the received signature SIGRU and the terminal certificate CERTU (Step S19), and if the verification is successful, the corresponding registered user information INFU is searched in the user information storage device using the terminal certificate CERTU or the terminal public key PKU contained in it (Step S20), to provide service for the user (Step S21).    [Non-patent literature 1] “Windows (registered trademark) CardSpace no shoukai (Introduction of Windows (registered trademark) CardSpace)”    [Online] Microsoft Corporation, [searched on Sep. 3, 2007], Internet <URL: http://www.microsoft.com/japan/msdn/net/general/IntroInfoCard.aspx>